Over recent years, Information/Content Centric Networking (ICN/CCN) is gaining momentum as a future technology for 5th generation mobile networks (“5G”) and other coming technologies for media distribution, device software upgrades and the Internet of Things (IoT). All major variants of ICN/CCN assume symmetric connections in-between consumers and producers of content. This creates issues with using unidirectional mechanisms such as 3rd Generation Partnership Project (3GPP) multicast/broadcast over the radio interface. In essence, these two different structures are difficult to combine.
FIG. 1 illustrates an operating principle of dominating ICN/CCN proposals today. This operating principle assumes that a link used in one direction—e.g. between Node 1 and Node 2 essentially being switches equipped with large caches for transporting content—to send content requests from subscribers is also used in the other direction to send the corresponding content back via Node 1 and Node 2 from a content provider to the subscribers. All links in ICN/CCN are therefore assumed to allow for bi-directional communication.
Multicast support is a key feature in ICN/CCN when transporting a particular content from a content provider to various subscribers/end users whom have requested content from that particular content provider. Whenever a node which has received content requests from several subscribers over different interfaces (each node being illustrated to comprise four interfaces in FIG. 1) receives requested content available for delivery, the node will deliver the requested content to the subscribers over a respective interface.
With reference to FIG. 1, if both Subscriber 1 and 2 request the same content, e.g. a live video stream, both subscribers will submit a request to Node 1. However, Node 1 will only forward a single request to Node 2 for that video stream, and Node 2 will as a result forward the single request towards the content provider. The content provider will thereafter return a single copy of the requested live stream to Node 2. Likewise, Node 2 will only send one copy of the live stream over its link to Node 1. Node 1 will then replicate the content of the video stream and send it to both Subscriber 1 and 2.
FIG. 2 illustrates transmission of live content over a 3GPP network. If ICN/CCN is implemented in a Radio Access Network (RAN) part of the system alongside a 3GPP core network, referred to as an Evolved Packet Core (EPC) network in case of implementation in a Long-Term Evolution (LTE) network, then it cannot be combined with Enhanced Multicast Broadcast Multimedia Service (eMBMS) for broadcasting/multicasting popular content since eMBMS requires termination in the core network.
Conversely, eMBMS as per standard 3GPP solutions requires an overlay over Internet Protocol (IP) in the mobile backhaul/3GPP core network for supporting multicasting. This is necessary since in eMBMS a set of new core nodes and interfaces are added in order to inject traffic to be multicasted across many eNodeBs.
There is hence no known solution for combining ICN-in-RAN with eMBMS. While eMBMS assumes a new set of nodes to be connected to the EPC network via a Packet Data Network Gateway (PGW) as well as support for IP and IP-based multicasting inside the RAN, ICN-in-RAN assumes none of this.
To the contrary, ICN-in-RAN aims to terminate radio bearers locally via cell site switches (similar to the nodes illustrated in FIG. 1) that support ICN. ICN-in-RAN only assumes services of a Mobility Management Entity (MME and Home Subscriber Server (HSS) in the EPC network in order to establish radio bearers for carrying ICN, for control plane signalling. However, ICN-in-RAN cannot make use of standard eMBMS, since eMBMS requires IP and EPC network user plane signalling.